System and method for exchanging data with smart cards

ABSTRACT

A system that includes an issuer system that receives, via a network, registration information from a mobile device, wherein the issuer system is associated with a financial institution that issues a smart card to a user and wherein the registration information includes an identifier of the mobile device, and a mobile device application associated with the issuer system, that when executed on a mobile device, communicates with the issuer system to validate the mobile device as a trusted device and enables the trusted device to communicate with the smart card and enable smart card management features mobile device application.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of, and claims priority under 35U.S.C. § 120 to, U.S. patent application Ser. No. 14/338,423, filed Jul.23, 2014, which claims priority to U.S. Provisional Patent ApplicationNo. 61/857,443, filed Jul. 23, 2013, the entire contents of which arefully incorporated herein by reference.

FIELD OF THE DISCLOSURE

The present disclosure relates to systems and methods for exchangingdata between mobile devices and smart cards.

BACKGROUND OF THE DISCLOSURE

Currently, a user having a smart card is dependent on physical locationsof smart card-accepting devices in order to read/write data onto thesmart card. This can be frustrating for smart card cardholders, as theyare limited as to where they can go to change the settings on theirsmart cards.

These and other drawbacks exist.

SUMMARY OF THE DISCLOSURE

Various example embodiment provide a system including an issuer systemthat receives, via a network, registration information from a mobiledevice, wherein the issuer system is associated with a financialinstitution that issues a smart card to a user and wherein theregistration information includes an identifier of the mobile device anda mobile device application associated with the issuer system, that whenexecuted on a mobile device, communicates with the issuer system tovalidate the mobile device as a trusted device and enables the trusteddevice to communicate with the smart card and enable smart cardmanagement features mobile device application.

In various embodiments, the trusted device communicates with the smartcard via near-field communications (NFC). Also, the smart card is anintegrated circuit card and/or a Europay, MasterCard and Visa card. Themanagement features include enabling offline updates to a personalidentification number (PIN) of the smart card.

Various embodiments also provide a system including an issuer systemthat receives via a network from a mobile device an inputted personalidentification number (PIN) associated with a smart card issued by theissuer system and transmits via a communication interface a validationmessage including the inputted PIN to the mobile device based on avalidation of the inputted PIN, and a mobile application executing on amobile device that receives the validation message, prompts the user toprovide the inputted PIN to the mobile device, compares, using aprocessor of the mobile device, the provided inputted PIN with theinputted PIN received in the validation message, and enablestransmission of the inputted PIN to the smart card if the providedinputted PIN matches the inputted PIN received in the validationmessage.

Various embodiments also provide a system including an issuer systemthat receives an authorization request for a transaction initiated by auser and transmits a verification request to a mobile application on amobile device of the user, wherein the issuer system receives theauthorization request from a merchant via an authorization network andwherein the issuer system transmits the verification request to themobile application via a network, and a mobile application on a mobiledevice of the user that receives the verification request, prompts theuser to input a personal identifier, receives an inputted personalidentifier, and communicates with a smart card of the user to verify theinputted personal identifier. The personal identifier is a personalidentification number (PIN) and the inputted personal identifier is aninputted PIN

Also, the mobile device includes a biometric data reader that interfaceswith the mobile application, and wherein the personal identifierincludes biometric data and the inputted personal identifier includesinputted biometric data. To verify the inputted personal identifier, themobile application receives the personal identifier from the smart cardand compares the received personal identifier to the inputted personalidentifier to determine whether the received and inputted personalidentifiers match. When there is a match, the issuer system receives,via the network, a verification message and authorizes the transactionbased on the received verification message.

In various embodiments, the authorization network and the network arethe same authorization network.

Also, the issuer system transmits, via the authorization network, anauthorization to a merchant associated with the transaction.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments of the present disclosure, together with furtherobjects and advantages, may best be understood by reference to thefollowing description taken in conjunction with the accompanyingdrawings, in the several Figures of which like reference numeralsidentify like elements, and in which:

FIG. 1 depicts a schematic diagram of a system for enabling read/writecapability to a smart card by way of a mobile application on a mobiledevice, according to an exemplary embodiment of the disclosure;

FIG. 2 depicts a schematic diagram of a method for providing a mobiledevice with a smart card management application, according to anexemplary embodiment of the disclosure;

FIG. 3 depicts a schematic diagram of a method for updating the offlinePIN on a smart card, according to an exemplary embodiment of thedisclosure;

FIG. 4 depicts a schematic diagram of a method for authenticating acardholder during an online transaction using smart card data, accordingto an exemplary embodiment of the disclosure

FIG. 5 depicts an example point of sale system according to anembodiment of the disclosure;

FIG. 6 depicts an example authorization network according to anembodiment of the disclosure; and

FIG. 7 depicts an example financial institution system according to anembodiment of the disclosure.

DETAILED DESCRIPTION OF THE EMBODIMENTS

The following description is intended to convey a thorough understandingof the embodiments described by providing a number of specific exemplaryembodiments and details involving systems and methods for providingread/write capabilities to a smart card by way of a secured applicationon a mobile device. It should be appreciated, however, that the presentdisclosure is not limited to these specific embodiments and details,which are exemplary only. It is further understood that one possessingordinary skill in the art, in light of known systems and methods, wouldappreciate the use of the invention for its intended purposes andbenefits in any number of alternative embodiments, depending on specificdesign and other needs. A financial institution and system supporting afinancial institution are used as examples for the disclosure. Thedisclosure is not intended to be limited to financial institutions only.

FIG. 1 depicts an exemplary embodiment of a system 100 for providingread/write interfaces between a smart card and a mobile device by way ofa secured application on a mobile device, according to variousembodiments of the disclosure. The system may include variousnetwork-enabled computer systems, including, as depicted in FIG. 1 forexample, a card issuer 104, cloud storage 105, a payment network 101,and a merchant 107. It is also noted that the system 100 illustratesonly a single instance of each component. It will be appreciated thatmultiple instances of these components may be used. Moreover, the system100 may include other devices not depicted in FIG. 1.

Other exemplary embodiments may disclose card issuer 104 and/or cloudstorage 105 as being integrated into payment network 101 or merchant107. As referred to herein, a network-enabled computer system and/ordevice may include, but is not limited to: e.g., any computer device, orcommunications device including, e.g., a server, a network appliance, apersonal computer (PC), a workstation, a mobile device, a phone, ahandheld PC, a personal digital assistant (PDA), a thin client, a fatclient, an Internet browser, or other device. The network-enabledcomputer systems may execute one or more software applications to, forexample, receive data as input from an entity accessing thenetwork-enabled computer system, process received data, transmit dataover a network, and receive data over a network. The one or morenetwork-enabled computer systems may also include one or more softwareapplications to enable the creation and provisioning of account servicesto mobile device 102 for use by cardholder 106.

The components depicted in FIG. 1 may store information in variouselectronic storage media. Electronic information, files, and documentsmay be stored in various ways, including, for example, a flat file,indexed file, hierarchical database, relational database, such as adatabase created and maintained with software from, for example, Oracle®Corporation, Microsoft® Excel file, Microsoft® Access file, or any otherstorage mechanism.

The components depicted in FIG. 1 may be coupled via one or morenetworks, such as, for example, payment network 101. Payment network 101may be used by one or more financial institutions and other entities tosecurely transmit data, such as data related to digital financialtransactions. Payment network 101 may be one or more of a wirelessnetwork, a wired network or any combination of wireless network andwired network. For example, network 101 may include one or more of afiber optics network, a passive optical network, a cable network, anInternet network, a satellite network, a wireless LAN, a Global Systemfor Mobile Communication (“GSM”), a Personal Communication Service(“PCS”), a Personal Area Network (“PAN”), D-AMPS, Wi-Fi, Fixed WirelessData, IEEE 802.11b, 802.15.1, 802.11n and 802.11g or any other wired orwireless network for transmitting and receiving a data signal. Network101 may comprise one or more secure communication channels for securelyexchanging information between mobile device 102, merchant 107, and/orcard issuer 104.

In addition, network 101 may include, without limitation, telephonelines, fiber optics, IEEE Ethernet 902.3, a wide area network (“WAN”), alocal area network (“LAN”), or a global network such as the Internet.Also network 101 may support an Internet network, a wirelesscommunication network, a cellular network, or the like, or anycombination thereof. Network 101 may further include one network, or anynumber of the exemplary types of networks mentioned above, operating asa stand-alone network or in cooperation with each other. Network 101 mayutilize one or more protocols of one or more network elements to whichthey are communicatively coupled. Network 101 may translate to or fromother protocols to one or more protocols of network devices. Althoughnetwork 101 is depicted as a single network, it should be appreciatedthat according to one or more embodiments, network 101 may comprise aplurality of interconnected networks, such as, for example, theInternet, a service provider's network, a cable television network,corporate networks, and home networks.

Cloud storage 105 may be a virtualized data storage pool hosted by oneor more third parties, card issuer 104, payment network 101, and/ormerchant 107. Cloud storage 105 may comprise one or more distributedservers and may be used to store data objects for access by mobiledevice 102, card issuer 104, and/or payment network 101. Cloud storage105 may be accessed through a web service application programminginterface (API), a cloud storage gateway or through a web-based userinterface. Cloud storage 105 may communicate data with issuer 104 andmobile device 102 using one or more networks. The networks may bedifferent from payment network 101. The networks may be secured. Thenetworks may be wireless.

Smart card 103 may be any pocket-sized card with one or more embeddedintegrated circuits (IC). Smart cards may also be referred to as ICcards or chip cards. Smart card 103 may be made of plastic and mayprovide identification, authentication, data storage and applicationprocessing. Smart card 103 may exchange data, such as payment data, withmerchant terminals or smart card-capable automatic teller machines(ATMs). Europay, Visa, and Mastercard (EMV) have developed standardsthat define the interaction at the physical, electrical, data andapplication levels between smart cards and smart card processing devicesfor financial transactions. There are standards based on ISO/IEC 7816for contact cards, and standards based on ISO/IEC 14443 for contactlesscards, which are both incorporated herein by reference.

Smart card 103 may be associated with one or more cardholders, such ascardholder 106. Smart card 103 may have been previously provided tocardholder 106 by issuer 104. Smart card 103 may store one or more unitsof exchange to allow cardholder 106 to purchase goods or services andhave the value of the purchase deducted from a balance on smart card103. Smart card 103 may store one or more offline PINs associated withcardholder 106. Before reading or writing data to the smart card at asmart card terminal, the cardholder 106 must first enter the offline PINon a keypad or touchscreen associated with the terminal. Smartcard 103may store biometric data associated with cardholder 106, such asfingerprint data. Cardholder 106 may use smartcard 103 to pay for goodsand services. Smartcard 103 may store account information for cardholder106. Smart card 103 may be associated with one or more account numbersfor accounts maintained by issuer 104, merchant 107, or by a third partyentity.

In various exemplary embodiments, cardholder 106 may be any individualor entity that desires to conduct a financial transaction using smartcard 103. Also, a cardholder may be a computer system associated with oroperated by such an individual or entity.

Card issuer 104 may be a financial institution. A financial institutionmay be, for example, a bank, other type of financial institution,including a credit card provider, for example, or any other entity thatoffers accounts to customers. An account may include any place,location, object, entity, or other mechanism for holding money orperforming transactions in any form, including, without limitation,electronic form. An account may be, for example, a credit card account,a prepaid card account, stored value card account, debit card account,check card account, payroll card account, gift card account, prepaidcredit card account, charge card account, checking account, rewardsaccount, line of credit account, credit account, mobile device account,an account or service that links to an underlying payment accountalready described, or mobile commerce account. An account may or may nothave an associated card, such as, for example, a credit card for acredit account or a debit card for a debit account. The account mayenable payment using biometric authentication, or contactless basedforms of authentication, such as QR codes or near-field communications.The account card may be associated or affiliated with one or more socialnetworking sites, such as a co-branded credit card.

Issuer 104 may store data related to cardholder 106 and smartcard 103.Issuer 104 may store the offline PIN for smart card 103, the name,address, email address, phone number, a username, password, biometricinformation, and other data that uniquely identifies cardholder 106.Card issuer 104 may store an online PIN for smart card 103. The onlinePIN may be the same as the offline PIN. The online PIN may be differentfrom the offline PIN in order to add an additional layer of security andfraud prevention.

Cardholder 106 may have one or more mobile devices, such as mobiledevice 102. Mobile device 102 may be, for example, a handheld PC, aphone, a smartphone, a PDA, a tablet computer, or other device. Mobiledevice 102 may include Near Field Communication (NFC) capabilities 102c, which may allow for communication with other devices by touching themtogether or bringing them into close proximity. Exemplary NFC standardsinclude ISO/IEC 18092:2004, which defines communication modes for NearField Communication Interface and Protocol (NFCIP-1). For example,mobile device 102 may be configured using the Isis Mobile Wallet™system, which is incorporated herein by reference. Other exemplary NFCstandards include those created by the NFC Forum.

Mobile device 102 may include one or more software applications, such ascard application 102 a. Card application 102 a may be a softwareapplication that enables mobile device 102 to securely exchange datawith smart card 103, payment network 101, cloud storage 105, merchant107, and/or card issuer 104. Card application 102 a may provide one ormore graphical user interfaces for cardholder 106 to pay for goods andservices using smart card 103, change the offline PIN for smart card103, submit the offline or online PIN, biometric information, and/orother authorization information to smart card 103, payment network 101,issuer 104, merchant 107, or cloud storage 105. These processes will bedescribed in greater detail in connection with FIGS. 2-4.

Mobile device 102 may be connected to one or more cardreaders 102 b.Cardreader 102 b may be a hardware device that is configured to readdata from smart card 103 and write data to smart card 103. Cardholder106 may use card application 102 a in conjunction with cardreader 102 bto read data from smart card 103 and write data to smart card 103.Mobile device 102 may also use NFC 102 c for wireless or contactlessdata exchange with smartcard 103.

Cardholder 106 may use mobile device 102 in conjunction with smart card103 to purchase goods or services from merchant 107. Merchant 107 may bea physical point of sale location. Merchant 107 may be an onlineretailer of goods or services. Smart card 103 may exchange paymentinformation directly with one or more smart card terminals associatedwith merchant 107. Smart card 103 may exchange payment information withmerchant 107 through card application 102 a on mobile device 102, and/orthrough payment network 101. This process will be described in greaterdetail in connection with FIGS. 2-4.

FIG. 5 depicts an example Point of Sale (PoS) device 500. PoS device 500may provide the interface at what a customer or end user makes a paymentto the merchant in exchange for goods or services. PoS device 500 mayinclude and/or cooperate with weighing scales, scanners, electronic andmanual cash registers, electronic funds transfer at point of sale(EFTPOS) terminals, touch screens and any other wide variety of hardwareand software available for use with PoS device 500. PoS device 500 maybe a retail point of sale system and may include a cash register and/orcash register-like computer components to enable purchase transactions.PoS device 500 also may be a hospitality point of sale system andinclude computerized systems incorporating registers, computers andperipheral equipment, usually on a computer network to be used inrestaurant, hair salons, hotels or the like. PoS device 500 may be awireless point of sale device similar to a PoS device described hereinor, for example a tablet computer that is configured to operate as a PoSdevice, including for example, software to cause the tablet computer toexecute point of sale functionality and a card reader such as forexample the Capital One® SparkPay card reader, the Square® reader,Intuit's® GoPayment reader, or the like. PoS device 500 also may be acloud-based point of sale system that can be deployed as software as aservice, which can be accessed directly from the Internet using, forexample, an Internet browser.

Referring to FIG. 5, an example PoS device 500 is shown. PoS device 500may include a controller 502, a reader interface 504, a data interface506, a smartcard reader 508, a magnetic stripe reader 510, a near-fieldcommunications (NFC) reader 512, a power manager 514, a keypad 516, anaudio interface 518, a touchscreen/display controller 520, and a display522. Also, PoS device 500 may be coupled with, integrated into orotherwise connected with a cash register/retail enterprise system 524.

In various embodiments, Controller 502 may be any controller orprocessor capable of controlling the operations of PoS device 500. Forexample, controller 502 may be a Intel® 2nd Generation Core™ i3 or i5 orPentium™ G850 processor or the like. Controller 502 also may be acontroller included in a personal computer, smartphone device, tablet PCor the like.

Reader interface 504 may provide an interface between the various readerdevices associated with PoS device 500 and PoS device 500. For example,reader interface 504 may provide an interface between smartcard reader508, magnetic stripe reader 510, NFC reader 512 and controller 502. Invarious embodiments, reader interface 504 may be a wired interface suchas a USB, RS232 or RS485 interface and the like. Reader interface 504also may be a wireless interface and implement technologies such asBluetooth, the 802.11(x) wireless specifications and the like. Readerinterface 504 may enable communication of information read by thevarious reader devices from the various reader devices to PoS device 500to enable transactions. For example, reader interface 504 may enablecommunication of a credit or debit card number read by a reader devicefrom that device to PoS device 500. In various embodiments, readerinterface 504 may interface between PoS device 500 and other devicesthat do not necessarily “read” information but instead receiveinformation from other devices.

Data interface 506 may allow PoS device 500 to pass communicate datathroughout PoS device and with other devices including, for example,cash register/retail enterprise system 524. Data interface 506 mayenable PoS device 500 to integrate with various customer resourcemanagement (CRM) and/or enterprise resource management (ERP) systems.Data interface 506 may include hardware, firmware and software that makeaspects of data interface 506 a wired interface. Data interface 506 alsomay include hardware, firmware and software that make aspects of datainterface 506 a wireless interface. In various embodiments, datainterface 506 also enables communication between PoS device otherdevices.

Smartcard reader 508 may be any electronic data input device that readsdata from a smart card. Smartcard reader 508 may be capable of supplyingan integrated circuit on the smart card with electricity andcommunicating with the smart card via protocols, thereby enabling readand write functions. In various embodiments, smartcard reader 508 mayenable reading from contact or contactless smart cards. Smartcard reader508 also may communicate using standard protocols including ISO/IEC7816, ISO/IEC 14443 and/or the like or proprietary protocols.

Magnetic stripe reader 510 may be any electronic data input device thatreads data from a magnetic stripe on a credit or debit card, forexample. In various embodiments, magnetic stripe reader 510 may includea magnetic reading head capable of reading information from a magneticstripe. Magnetic stripe reader 510 may be capable of reading, forexample, cardholder information from tracks 1, 2, and 3 on magneticcards. In various embodiments, track 1 may be written on a card withcode known as DEC SIXBIT plus odd parity and the information on track 1may be contained in several formats (e.g., ormat A, which may bereserved for proprietary use of the card issuer; format B; format C-Mwhich may be reserved for us by ANSI subcommittee X3B10; and format N-Z,which may be available for use by individual card issuers). In variousembodiments, track 2 may be written with a 5-bit scheme (4 data bitsplus 1 parity). Track 3 may be unused on the magnetic stripe. In variousembodiments, track 3 transmission channels may be used for transmittingdynamic data packet information to further enable enhanced token-basedpayments.

NFC reader 512 may be any electronic data input device that reads datafrom a NFC device. In an exemplary embodiment, NFC reader 512 may enableIndustry Standard NFC Payment Transmission. For example, the NFC reader512 may communicate with a NFC enabled device to enable two loopantennas to form an air-core transformer when placed near one another byusing magnetic induction. NFC reader 512 may operate at 13.56 MHz or anyother acceptable frequency. Also, NFC reader 512 may enable a passivecommunication mode, where an initiator device provides a carrier field,permitting answers by the target device via modulation of existingfields. Additionally, NFC reader 512 also may enable an activecommunication mode by allowing alternate field generation by theinitiator and target devices.

In various embodiments, NFC reader 512 may deactivate an RF field whileawaiting data. NFC reader 512 may receive communications containingMiller-type coding with varying modulations, including 100% modulation.NFC reader 512 also may receive communications containing Manchestercoding with varying modulations, including a modulation ratio ofapproximately 10%, for example. Additionally, NFC reader 512 may becapable of receiving and transmitting data at the same time, as well aschecking for potential collisions when the transmitted signal andreceived signal frequencies differ.

NFC reader 512 may be capable of utilizing standardized transmissionprotocols, for example but not by way of limitation, ISO/IEC 14443 A/B,ISO/IEC 18092, MiFare, FeliCa, tag/smartcard emulation, and the like.Also, NFC reader 512 may be able to utilize transmission protocols andmethods that are developed in the future using other frequencies ormodes of transmission. NFC reader 512 also may be backwards-compatiblewith existing payment techniques, such as, for example RFID. Also, NFCreader 512 may support transmission requirements to meet new andevolving payment standards including internet based transmissiontriggered by NFC. In various embodiments, NFC reader 512 may utilizeMasterCard's® PayPass and/or Visa's® PayWave and/or American Express'®ExpressPay systems to enable transactions.

Although not shown and described, other input devices and/or readers,such as for example, barcode readers and the like are contemplated.

Power manager 514 may be any microcontroller or integrated circuit thatgoverns power functions of PoS device 500. Power manager 514 mayinclude, for example, firmware, software, memory, a CPU, a CPU,input/output functions, timers to measure intervals of time, as well asanalog to digital converters to measure the voltages of the main batteryor power source of PoS device 500. In various embodiments, Power manager514 remain active even when PoS device 500 is completely shut down,unused, and/or powered by the backup battery. Power manager 514 may beresponsible for coordinating many functions, including, for example,monitoring power connections and battery charges, charging batterieswhen necessary, controlling power to other integrated circuits withinPoS device 500 and/or other peripherals and/or readers, shutting downunnecessary system components when they are left idle, controlling sleepand power functions (on and off), managing the interface for built-inkeypad and trackpads, and/or regulating a real-time clock (RTC).

Keypad 516 may any input device that includes a set of buttons arranged,for example, in a block or pad and may bear digits, symbols and/oralphabetical letters. Keypad 516 may be a hardware-based ormechanical-type keypad and/or implemented in software and displayed on,for example, a screen or touch screen to form a keypad. Keypad 516 mayreceive input from a user that pushed or otherwise activates one or morebuttons on keypad 516 to provide input.

Audio interface 518 may be any device capable of providing audio signalsfrom PoS device 500. For example, audio interface may be a speaker orspeakers that may produce audio signals. In various embodiments, audiointerface 518 may be integrated within PoS device 500. Audio interface518 also may include components that are external to PoS device 500.

Touchscreen/display control 520 may be any device or controller thatcontrols an electronic visual display. Touchscreen/display control 520may allow a user to interact with PoS device 500 through simple ormulti-touch gestures by touching a screen or display (e.g., display522). Touchscreen/display control 520 may be configured to control anynumber of touchscreens, including, for example, resistive touchscreens,surface acoustic wave touchscreens, capacitive touchscreens, surfacecapacitance touchscreens, projected capacitance touchscreens, mutualcapacitance touchscreens, self-capacitance touchscreens, infrared gridtouchscreens, infrared acrylic projection touchscreens, opticaltouchscreens, touchscreens based on dispersive signal technology,acoustic pulse recognition touchscreens, and the like. In variousembodiments, touchscreen/display control 520 may receive inputs from thetouchscreen and process the received inputs. Touchscreen/display control520 also may control the display on PoS device 500, thereby providingthe graphical user interface on a display to a user of PoS device 500.

Display 522 may be any display suitable for a PoS device. For example,display 522 may be a TFT, LCD, LED or other display. Display 522 alsomay be a touchscreen display that for example allows a user to interactwith PoS device 500 through simple or multi-touch gestures by touching ascreen or display (e.g., display 522). Display 522 may include anynumber of touchscreens, including, for example, resistive touchscreens,surface acoustic wave touchscreens, capacitive touchscreens, surfacecapacitance touchscreens, projected capacitance touchscreens, mutualcapacitance touchscreens, self-capacitance touchscreens, infrared gridtouchscreens, infrared acrylic projection touchscreens, opticaltouchscreens, touchscreens based on dispersive signal technology,acoustic pulse recognition touchscreens, and the like. In variousembodiments, 522 may receive inputs from control gestures provided by auser. Display 522 also may display images, thereby providing thegraphical user interface to a user of PoS device 500.

Cash register/retail enterprise system 524 may me any device or devicesthat cooperate with PoS device 500 to process transactions. Cashregister/retail enterprise system 524 may be coupled with othercomponents of PoS device 500 via, for example, a data interface (e.g.,data interface 506) as illustrated in FIG. 5. Cash register/retailenterprise system 524 also may be integrated into PoS device 500.

In various embodiments, cash register/retail enterprise system 524 maybe a cash register. Example cash registers may include, for example,mechanical or electronic devices that calculate and record salestransactions. Cash registers also may include a cash drawer for storingcash and may be capable of printing receipts. Cash registers also may beconnected to a network to enable payment transactions. Cash registersmay include a numerical pad, QWERTY or custom keyboard, touch screeninterface, or a combination of these input methods for a cashier toenter products and fees by hand and access information necessary tocomplete the sale.

In various embodiments, cash register/retail enterprise system 524 maycomprise an retail enterprise system and/or a customer relationshipmanagement system. Retail enterprise system 524 may enable retainenterprises to manage operations and performance across a retailoperation. Retail enterprise system 524 may be a stand-alone applicationin, for example, individual stores, or may be interconnected via anetwork. Retail enterprise system 524 may include various point of salecapabilities, including the ability to, for example, customize andresize transaction screens, work with a “touch screen” graphical userinterface, enter line items, automatically look up price (sales,quantity discount, promotional, price levels), automatically computetax, VAT, look up quantity and item attribute, display item picture,extended description, and sub-descriptions, establish default shippingservices, select shipping carrier and calculate shipping charges byweight/value, support multi-tender transactions, including cash, check,credit card, and debit card, accept food stamps, place transactions onhold and recall, perform voids and returns at POS, access online creditcard authorizations and capture electronic signatures, integrate debitand credit card processing, ensure optional credit card discounts withaddress verification, support mix-and-match pricing structure, discountentire sale or selected items at time of sale, add customer account,track customer information, including total sales, number of visits, andlast visit date. issue store credit, receive payment(s) for individualinvoices, process deposits on orders, search by customer's ship-toaddress, create and process layaway, back orders, work orders, and salesquotes, credit items sold to selected sales reps, view daily sales graphat the PoS, view and print journals from any register, preview, search,and print journals by register, batch, and/or receipt number, print X,Z, and ZZ reports, print receipts, invoices, and pick tickets withlogos/graphics, print kit components on receipt, reprint receipts, enteremployee hours with an integrated time clock function, and/or sell whenthe network/server is down with an offline PoS mode. Retail enterprisesystem 524 also may include inventory control and tracking capabilities,reporting tools, customer management capabilities, employee managementtools, and may integrate with other accounting software.

In various embodiments cash register/retail enterprise system 524 may bea hospitality PoS. In such embodiments, retail enterprise system 524 mayinclude hospitality PoS software (e.g, Aloha PoS Restaurant softwarefrom NCR®, Micros® RES and Symphony software and the like), hospitalitymanagement software, and other hardware and software to facilitatehospitality operations.

FIG. 6 illustrates an example system 600 and method for cardauthorization. As shown and described in FIG. 6, merchants, cardholdersand financial institutions may be connected with a card associationnetwork to enable secure transactions and timely payments. System 600may include a cardholder 602, merchant 604, Acquirer 610,Association/Interchange 616, and card issuer 618.

Cardholder 602 may be any card holder, including a credit card holder,debit card holder, stored value card holder and the like. Cardholder 602may possess a plastic card or carry a device (e.g., a mobile device)that securely stores card credentials and is capable of transmitting thecard credentials to, for example, a PoS terminal (e.g., terminal 606).Cardholder 602 may interact with a merchant (e.g., merchant 604) bypresenting a card or card credentials to a terminal (e.g., terminal606).

Merchant 604 may be any merchant that accepts payment from a cardholder,for example. Merchant 604 may be any retailer, service provider,business entity, or individual that accepts payments. Merchant 604 mayinclude software, firmware and hardware for accepting and/or processingpayments. For example, as illustrated in FIG. 6, merchant 604 mayinclude a terminal 606 and a payment gateway 608. Terminal 606 andpayment gateway 608 may comprise the physical or virtual device(s) usedby merchant 604 to communicate information to front-end processor 612 ofacquirer 610. Terminal 606 may be similar to PoS system [Y00] as shownand described in Figure Y. In various embodiments, payment gateway 608may be an e-commerce application service provider service thatauthorizes payments for merchants. As such, payment gateway 608 may be avirtual equivalent of a PoS terminal and interface with, for example, abilling system of merchant 604 and pass data to front-end processor 612of acquirer 610.

Acquirer 610 may be, for example, a financial institution or bank, thatholds the contract for providing payment processing services to merchant604. Merchant 604 may have a merchant account that may serve as acontract under which Acquirer 610 may extend a line of credit to amerchant who wishes to accept, for example, credit card transactions. Asshown in FIG. 6, Acquirer 610 may be associated with front-end processor612 and back-end processor 614.

In various examples, front-end processor 612 may be a platform that cardterminal 606 and/or payment gateway 608 communicate with when approvinga transaction. Front-end processor 612 may include hardware, firmware,and software to process transactions. Front-end processor 612 may beresponsible for the authorization and capture portion of credit cardtransaction. Front-end processor 612 also may include additionalfront-end platform interconnections to support, for example, ACH anddebit transactions.

Backend processor 614 may be a platform that takes captured transactionsfrom front-end processor 612 and settles them through an Interchangesystem (e.g., association/interchange 616). Back-end processor 614 maygenerate, for example, daily ACH files for merchant settlement. Back-endprocessor 614 also may handle chargeback handling, retrieval request andmonthly statements.

Association/interchange 616 may be the consumer payment system whosemembers are the financial institutions that issue payment cards and/orsign merchant to accept payment cards. Example associations/interchanges616 may include, Visa®, MasterCard®, and AmericanExpress®.Association/interchange 616 may include one or more computer systems andnetworks to process transactions.

Issuer 618 may be a financial institution that issues payment cards andmaintains a contract with cardholders for repayment. In variousembodiments, issuer 618 may issue credit, debit, and/or stored valuecards, for example. Example issuers may include, Capital One, Bank ofAmerica, Citibank, and the like.

In various embodiments, processing a payment card transaction mayinvolves two stages: (1) authorization and (2) clearing and settlement.Authorization may refer to an electronic request that is sent throughvarious parties to either approve or decline the transaction. Clearingand Settlement may refer to settlement of the parties' settle accountsto enable the parties to get paid.

During authorization, cardholder 602 may present payment card as payment(601A) at merchant 604 PoS terminal 606, for example. Merchant 604 mayenter card into a physical PoS terminal 606 or submit a credit cardtransaction to a payment gateway 608 on behalf of cardholder 602 viasecure connection from a Web site, retail location, or a wirelessdevice.

Payment gateway 608 may receive the secure transaction information(603A) and may pass the secure transaction information (605A) via asecure connection to the merchant acquirer's 610 front-end processor612.

Front-end processor 612 may submit the transaction (607A) toassociation/interchange 616 (e.g., a network of financial entities thatcommunicate to manage the processing, clearing and settlement of creditcard transactions). Association/interchange 616 may route thetransaction (609A) to the customer's Issuer 618. Issuer 618 may approveor decline the transaction and passes the transaction results back(611A) through association/interchange 616. Association/interchange thenmay relay the transaction results (613A) to front-end processor 612.

Front-end processor 612 may relay the transaction results (615A) back tothe payment gateway 608 and/or terminal 606. Payment gateway 608 maystore the transaction results and sends them to merchant 604. Merchant604 may receive the authorization response and complete the transactionaccordingly.

During settlement, merchant 604 may deposit the transaction receipt(621S) with acquirer 610 via, for example, a settlement batch. Capturedauthorizations may be passed (623S) from front-end processor 612 to theback-end processor 614 for settlement. Back-end processor may generatesACH files for merchant settlement. Acquirer may submit settlement files(625S, 627S) to Issuer 618 for reimbursement via association/interchange616. Issuer 618 may post the transaction and pay merchant 604 (629S,631S, 633S).

FIG. 7 depicts an example system 700 that may enable a financialinstitution, for example, to provide network services to its customers.As shown in FIG. 7, system 700 may include a client device 702, anetwork 704, a front-end controlled domain 706, a back-end controlleddomain 712, and a backend 718. Front-end controlled domain 706 mayinclude one or more load balancers 708 and one or more web servers 710.Back-end controlled domain 712 may include one or more load balancers714 and one or more application servers 716.

Client device 702 may be a network-enabled computer: As referred toherein, a network-enabled computer may include, but is not limited to:e.g., any computer device, or communications device including, e.g., aserver, a network appliance, a personal computer (PC), a workstation, amobile device, a phone, a handheld PC, a personal digital assistant(PDA), a thin client, a fat client, an Internet browser, or otherdevice. The one or more network-enabled computers of the example system700 may execute one or more software applications to enable, forexample, network communications.

Client device 702 also may be a mobile device: For example, a mobiledevice may include an iPhone, iPod, iPad from Apple® or any other mobiledevice running Apple's iOS operating system, any device running Google'sAndroid® operating system, including for example, Google's wearabledevice, Google Glass, any device running Microsoft's Windows® Mobileoperating system, and/or any other smartphone or like wearable mobiledevice.

Network 704 may be one or more of a wireless network, a wired network,or any combination of a wireless network and a wired network. Forexample, network 704 may include one or more of a fiber optics network,a passive optical network, a cable network, an Internet network, asatellite network, a wireless LAN, a Global System for MobileCommunication (GSM), a Personal Communication Service (PCS), a PersonalArea Networks, (PAN), D-AMPS, Wi-Fi, Fixed Wireless Data, IEEE 802.11b,802.15.1, 802.11n, and 802.11g or any other wired or wireless networkfor transmitting and receiving a data signal.

In addition, network 704 may include, without limitation, telephonelines, fiber optics, IEEE Ethernet 902.3, a wide area network (WAN), alocal area network (LAN) or a global network such as the Internet. Also,network 704 may support an Internet network, a wireless communicationnetwork, a cellular network, or the like, or any combination thereof.Network 704 may further include one network, or any number of exampletypes of networks mentioned above, operating as a stand-alone network orin cooperation with each other. Network 704 may utilize one or moreprotocols of one or more network elements to which they arecommunicatively couples. Network 704 may translate to or from otherprotocols to one or more protocols of network devices. Although network704 is depicted as a single network, it should be appreciated thataccording to one or more embodiments, network 704 may comprise aplurality of interconnected networks, such as, for example, theInternet, a service provider's network, a cable television network,corporate networks, and home networks.

Front-end controlled domain 706 may be implemented to to providesecurity for backend 718. Load balancer(s) 708 may distribute workloadsacross multiple computing resources, such as, for example computers, acomputer cluster, network links, central processing units or diskdrives. In various embodiments, load balancer(s) 710 may distributeworkloads across, for example, web server(S) 716 and/or backend 718systems. Load balancing aims to optimize resource use, maximizethroughput, minimize response time, and avoid overload of any one of theresources. Using multiple components with load balancing instead of asingle component may increase reliability through redundancy. Loadbalancing is usually provided by dedicated software or hardware, such asa multilayer switch or a Domain Name System (DNS) server process.

Load balancer(s) 708 may include software that monitoring the port whereexternal clients, such as, for example, client device 702, connect toaccess various services of a financial institution, for example. Loadbalancer(s) 708 may forward requests to one of the application servers716 and/or backend 718 servers, which may then reply to load balancer708. This may allow load balancer(s) 708 to reply to client device 702without client device 702 ever knowing about the internal separation offunctions. It also may prevent client devices from contacting backendservers directly, which may have security benefits by hiding thestructure of the internal network and preventing attacks on backend 718or unrelated services running on other ports, for example.

A variety of scheduling algorithms may be used by load balancer(s) 708to determine which backend server to send a request to. Simplealgorithms may include, for example, random choice or round robin. Loadbalancers 708 also may account for additional factors, such as aserver's reported load, recent response times, up/down status(determined by a monitoring poll of some kind), number of activeconnections, geographic location, capabilities, or how much traffic ithas recently been assigned.

Load balancers 708 may be implemented in hardware and/or software. Loadbalancer(s) 708 may implement numerous features, including, withoutlimitation: asymmetric loading; Priority activation: SSL Offload andAcceleration; Distributed Denial of Service (DDoS) attack protection;HTTP compression; TCP offloading; TCP buffering; direct server return;health checking; HTTP caching; content filtering; HTTP security;priority queuing; rate shaping; content-aware switching; clientauthentication; programmatic traffic manipulation; firewall; intrusionprevention systems.

Web server(s) 710 may include hardware (e.g., one or more computers)and/or software (e.g., one or more applications) that deliver webcontent that can be accessed by, for example a client device (e.g.,client device 702) through a network (e.g., network 704), such as theInternet. In various examples, web servers, may deliver web pages,relating to, for example, online banking applications and the like, toclients (e.g., client device 702). Web server(s) 710 may use, forexample, a hypertext transfer protocol (HTTP or sHTTP) to communicatewith client device 702. The web pages delivered to client device mayinclude, for example, HTML documents, which may include images, stylesheets and scripts in addition to text content.

A user agent, such as, for example, a web browser, web crawler, ornative mobile application, may initiate communication by making arequest for a specific resource using HTTP and web server 710 mayrespond with the content of that resource or an error message if unableto do so. The resource may be, for example a file on stored on backend718. Web server(s) 710 also may enable or facilitate receiving contentfrom client device 702 so client device A02 may be able to, for example,submit web forms, including uploading of files.

Web server(s) also may support server-side scripting using, for example,Active Server Pages (ASP), PHP, or other scripting languages.Accordingly, the behavior of web server(s) 710 can be scripted inseparate files, while the actual server software remains unchanged.

Load balancers 714 may be similar to load balancers 708 as describedabove.

Application server(s) 716 may include hardware and/or software that isdedicated to the efficient execution of procedures (e.g., programs,routines, scripts) for supporting its applied applications. Applicationserver(s) 716 may comprise one or more application server frameworks,including, for example, Java application servers (e.g., Java platform,Enterprise Edition (Java EE), the .NET framework from Microsoft®, PHPapplication servers, and the like). The various application serverframeworks may contain a comprehensive service layer model. Also,application server(s) 716 may act as a set of components accessible to,for example, a financial institution or other entity implementing system700, through an API defined by the platform itself. For Webapplications, these components may be performed in, for example, thesame running environment as web server(s) 710, and application servers716 may support the construction of dynamic pages. Application server(s)716 also may implement services, such as, for example, clustering,fail-over, and load-balancing. In various embodiments, where applicationserver(s) 716 are Java application servers, the web server(s) 716 maybehaves like an extended virtual machine for running applications,transparently handling connections to databases associated with backend718 on one side, and, connections to the Web client (e.g., client device702) on the other.

Backend 718 may include hardware and/or software that enables thebackend services of, for example, a financial institution or otherentity that maintains a distributes system similar to system 700. Forexample, backend 718 may include, a system of record, online bankingapplications, a rewards platform, a payments platform, a lendingplatform, including the various services associated with, for example,auto and home lending platforms, a statement processing platform, one ormore platforms that provide mobile services, one or more platforms thatprovide online services, a card provisioning platform, a general ledgersystem, and the like. Backend 718 may be associated with variousdatabases, including account databases that maintain, for example,customer account information, product databases that maintaininformation about products and services available to customers, contentdatabases that store content associated with, for example, a financialinstitution, and the like. Backend 718 also may be associated with oneor more servers that enable the various services provided by system 700.

Referring now to FIG. 2, FIG. 2 is a flow chart illustrating a methodfor providing card application 102 a to mobile device 102. The method200 shown in FIG. 2 can be executed or otherwise performed by one ormore combinations of various systems. The method 200 as described belowmay be carried out by the system for providing read/write interfacesbetween a smart card and a mobile device by way of a secured applicationon the mobile device, as shown in FIGS. 1 and 5-7, by way of example,and various elements of that system are referenced in explaining themethod of FIG. 2. Each block shown in FIG. 2 represents one or moreprocesses, methods, or subroutines in the exemplary method 200.Referring to FIG. 2, the exemplary method 200 may begin at block 201.

In block 201, method 200 may include receiving registration information.The registration information may be received by issuer 104 from mobiledevice 102. The registration information may include a device identifierassociated with the mobile device, such as a mobile phone number and/ora MAC address of the mobile device and/or the like. The registrationinformation may include a username, password, social security number,email address, biometric information, or other information that uniquelyidentifies cardholder 106. Issuer 104 may store the registrationinformation in one or more databases and associate it with cardholder106 and mobile device 102. Cardholder 106 may provide the registrationinformation to issuer 104 via payment network 101 and/or network 704. Inresponse to receiving the registration information, issuer 104 may sendone or more notifications, such as an email or text message, to mobiledevice 102, requesting verification information. The verificationinformation may be an email containing a hyperlink to a verificationpage hosted by issuer 104. The cardholder 106 may click on the link andbe directed to the verification page, which may complete theregistration process, allowing mobile device 102 to download cardapplication 102 a. Verification via text messaging also may be used.Method 200 may proceed to block 202.

At block 202, method 200 may transmit a smart card managementapplication to mobile device 102. The application may be transmitted byissuer 104, a financial institution, and/or the like. The applicationmay be card application 102 a. For example, the application may be anative mobile banking application, a mobile optimized web interfaceand/or the like. Cardholder 106 may download and install cardapplication 102 a on mobile device 102. Card application 102 a mayprovide one or more graphical user interfaces allowing cardholder 106 touser mobile device 102 to exchange data with issuer 104 and/or smartcard 103. Card application 102 a may prompt cardholder 106 to enter anonline PIN for smart card 103. The online PIN may have been previouslycreated by issuer 104 and associated with smart card 103 and cardholder106 in one or more databases. Issuer 104 may have provided the PIN overa secure channel, such as payment network 101, to mobile device 102. Theonline PIN may have been provided in an email or text message.Cardholder may use a keypad or touchscreen on mobile device 102 to enterthe received online PIN or other unique password. Issuer 104 and/orfinancial institution may receive the entered online PIN and compare itto the online PIN associated with smart card 103 and cardholder 106. Ifthe PINs match, issuer 104 may verify that mobile device 102 is atrusted device, and that card application 102 a is enabled to performmanagement operations with smart card 103, for example, as will bedescribed in connection with FIGS. 3 and 4. Method 200 may proceed toblock 203.

In block 203, method 200 may transmit updated scripts to mobile device102. Issuer 104 may transmit updated scripts to mobile device 102 usingpayment network 101. Issuer 104 may transmit updated scripts to mobiledevice 102 using, for example, cloud storage 105. Cardholder 106 may usemobile device 102 to check cloud storage 105 for updates. Also, cloudstorage 105 may automatically “push” updated scripts to mobile device102 as they are received from issuer 104. The scripts may be softwaremodules that can be downloaded to mobile device 102 and later invoked bycard application 102 a to perform one or more functions involving smartcard 103. Scripts may include an Update PIN script, which enables thecard application 102 a to update the offline PIN of smart card 103and/or a provision card script, which may provision an account number tothe card. Scripts may include loyalty programs, reward programs, deals,or other offers from issuer 104, merchant 107, or one or more thirdparties.

For example, a Rewards script may enable card application 102 to storerewards points on smart card 103. Smart card 103 may maintain a rewardspoints balance that cardholder 106 can use to buy goods or services.

FIG. 3 is a flow chart illustrating a method updating the offline PIN ona smart card, for example, using a mobile application on a mobiledevice. The method 300 shown in FIG. 3 can be executed or otherwiseperformed by one or more combinations of various systems. The method 300as described below may be carried out by the system for providingread/write interfaces between a smart card and a mobile device by way ofa secured application on the mobile device, as shown in FIGS. 1 and 5-7,by way of example, and various elements of that system are referenced inexplaining the method of FIG. 3. Each block shown in FIG. 3 representsone or more processes, methods, or subroutines in the exemplary method300. Referring to FIG. 3, the exemplary method 300 may begin at block301.

At block 301, cardholder 106 may login to card application 102 a onmobile device 102. Cardholder 106 may provide a username and/or passwordand/or other similar login credentials to securely access cardapplication 102 a, using a touchscreen and/or keypad on mobile device102. Cardholder 106 may provide biometric identification to mobiledevice 102. Cardholder may select one or more scripts on cardapplication 102 a, such as the Update PIN script. Method 300 may proceedto block 302.

At block 302, cardholder 106 may enter a new offline PIN for smart card103 in response to a prompt from mobile device 102. The new PIN may be aseries of letters or numbers chosen by cardholder 106. Cardholder 106may enter the new offline PIN using a touchscreen or keypad associatedwith mobile device 102. Method 300 may proceed to block 303.

At block 303, card application 102 a may “package” the new offline PINand transmit the new offline PIN to issuer 104 or cloud storage 105.Cloud storage 105 may transmit the offline PIN to issuer 104 via paymentnetwork 101. Cloud storage 105 may transmit the new offline PIN toissuer 104 via a different network than payment network 101. Method 300may proceed to block 304.

At block 304, Issuer 104 may update the previously stored offline PINbased on the new offline PIN. The previously stored offline PIN may beassociated with cardholder 106 and smart card 103 in one or moredatabases associated with issuer 104. Issuer 104 may delete thepreviously stored offline PIN and replace it with the new offline PIN.Issuer 104 may sync the new offline PIN with the stored online PIN.Method 300 may proceed to block 305.

At block 305, Issuer 104 may transmit a validation request to mobiledevice 102. The validation request may be first transmitted to cloudstorage 105, then pushed to mobile device 102. The validation requestmay be transmitted to mobile device 102 via payment network 101 via forexample, an email message, text message, and or the like. Validationrequest may prompt the cardholder 106 to provide validation information.Method 300 may proceed to block 306.

At block 306, card application 102 a may receive validation informationfrom the cardholder 106. Card application 102 a may prompt thecardholder 106 to validate the new offline PIN. Card application 102 amay display the new offline PIN on the screen of mobile device 102 andrequest input from the cardholder 106 (such as a button, check box, orother interactive display that receives input from cardholder 106).Cardholder 106 may confirm the accuracy of the new offline PIN.Cardholder 106 may cancel the process or refuse to validate the newoffline PIN. If cardholder 106 does not validate the new offline PIN,method 300 may end. In other embodiments, card application 102 a mayrequest confirmation from cardholder 106 that he wishes to keep his oldoffline PIN. Method 300 may proceed to block 307.

At block 307, if the offline PIN is validated, card application 102 amay write the updated offline PIN to smart card 103. Card application102 a may prompt cardholder 106 to “tap” mobile device 102 to smart card103. This may involve bringing smart card 103 in close physicalproximity to mobile device 102 or physically touching smart card 103with mobile device 102. Doing this may allow card application 102 a totransmit the new offline PIN to smart card 103 using NFC 102 c. Theupdated offline PIN also may be transmitted by having cardholder 106 dipsmart card 103 towards card reader device 102 b. Card application 102 amay transmit one or more scripts that includes commands for smart card103 to delete its current offline PIN and replace it with the newoffline PIN in smart card 103's memory. Smartcard 103 may store the newoffline PIN in response to receiving the one or more scripts or commandsfrom card application 102 a. In this way, a cardholder can use hismobile device to update the PIN on his smart card without having to finda smart card capable terminal or ATM.

FIG. 4 is a flow chart illustrating a method for authenticating acardholder to a merchant using data read from a smart card using amobile device. The method 400 shown in FIG. 4 can be executed orotherwise performed by one or more combinations of various systems. Themethod 400 as described below may be carried out by the system forproviding read/write interfaces between a smart card and a mobile deviceby way of a secured application on the mobile device, as shown in FIG.1, by way of example, and various elements of that system are referencedin explaining the method of FIG. 4. Each block shown in FIG. 4represents one or more processes, methods, or subroutines in theexemplary method 400. Referring to FIG. 4, the exemplary method 400 maybegin at block 401.

At block 401, cardholder 106 may attempt to purchase one or more goodsor services from merchant 107. Merchant 107 may be an online merchant.Cardholder 106 may access the merchant's website (such as a clothingwebsite), select several dress shirts to purchase, place them in anonline shopping cart, and proceed to checkout. At checkout, merchant 107may prompt cardholder 106 for payment information. Cardholder 106 mayprovide one or more account numbers or card numbers associated withSmart card 103 in an attempt to purchase the shirts using smart card103. Merchant 107 may receive this information and package it asauthorization information. Method 400 may proceed to block 402.

At block 402, merchant 107 may route authorization information to issuer104. The authorization information may include the account numberassociated with smart card 103 and/or cardholder 106. Merchant 107 mayroute the authorization information via payment network 101. In variousembodiments, a merchant may route the authorization information in amanner as shown and described in, for example, FIG. 6. Referring back toFIG. 4, method 400 may proceed to block 403.

At block 403, issuer 104 may prompt cardholder 106 for verification.Issuer 104 may send one or more signals to mobile device 102. Thesesignals may cause mobile device 102 to invoke card application 102 a.Card application 102 a may prompt cardholder 106 for the offline PIN forsmart card 103. Card application 102 a may cause one or more GUIs to bedisplayed on the screen of mobile device 102, and request thatcardholder 106 enter his offline PIN using a keypad or touchscreen formobile device 102. Method 400 may proceed to block 404.

At block 404, card application 102 a may receive the cardholder'soffline PIN and authenticate it with smart card 103. Cardholder 106 mayenter his offline PIN on mobile device 102 in response to the promptfrom card application 102 a. Card application 102 a may invoke one ormore scripts, such as an Authenticate Cardholder script, to request theoffline PIN stored on smart card 103. As with the Update PIN functiondescribed in connection with FIG. 3, invoking the AuthenticateCardholder script may cause card application 102 a to prompt cardholder106 to tap or touch smart card 103 to mobile device 102 in order thatcard application 102 a may read and/or receive the offline PIN fromsmart card 103. The offline PIN on smart card 103 may be read using NFC102 c. In other embodiments, card application 102 a may promptcardholder 106 to dip smart card 103 towards cardreader device 102 b andread the offline PIN on smart card 103.

Card application 102 a may read the offline PIN stored on smart card 103and compare it to the PIN entered by cardholder 106. In otherembodiments, card application 102 a may receive biometric data stored onsmart card 103 and compare it to biometric data input by cardholder 106(such as a fingerprint). Method 400 may proceed to block 405.

At block 405, mobile device 102 may transmit the results of thecomparison to issuer 104. If the results indicate a match (for example,if the PIN entered by the cardholder on mobile device 102 matches theoffline PIN stored on smart card 103), issuer 104 may send anauthorization signal to merchant 107, authorizing the transaction tomove forward. If the comparison indicates no match, or insufficientmatch, issuer 104 may send a signal to merchant 107, indicating theerror, and prompting merchant 107 to request that cardholder 106 attemptto enter his PIN again. In other embodiments, merchant 107 may end thetransaction. If issuer 104 authorizes the transaction, merchant 107 mayproceed to checkout and allow the cardholder to pay for the purchasedshirts. In this way, card application 102 a may provide a way for acardholder to use a smart card as a method of authentication when makingonline (non face-to-face or card not present) purchases. In variousembodiments, blocks 403-405 may occur during in conjunction with theauthorization methods described in FIGS. 4 and 6.

It is further noted that the software described herein maybe tangiblyembodied in one of more physical media, such as, but not limited to, acompact disc (CD), a digital versatile disc (DVD), a floppy disk, a harddrive, read only memory (ROM), random access memory (RAM), as well asother physical media capable of storing software, or combinationsthereof. Moreover, the figures illustrate various components (e.g.,servers, computers, processors, etc.) separately. The functionsdescribed as being performed at various components may be performed atother components, and the various components bay be combined orseparated. Other modifications also may be made.

In the preceding specification, various preferred embodiments have beendescribed with references to the accompanying drawings. It will,however, be evident that various modifications and changes may be madethereto, and additional embodiments may be implemented, withoutdeparting from the broader scope of the invention as set forth in theclaims that follow. The specification and drawings are accordingly to beregarded as an illustrative rather than restrictive sense.

What is claimed is:
 1. A non-transitory, computer-readable mediumstoring instructions that, when executed by a processor of a mobiledevice, cause the processor to perform a method of transactionauthentication comprising: receiving a verification request from anissuer system, the verification request corresponding to a requestedtransaction associated with a financial account of a customer, thefinancial account associated with a smart card; receiving anauthentication factor inputted by the customer to the mobile device;communicating with the smart card to compare the authentication factorwith a stored authentication factor stored on the smart card; based on acomparison of the received authentication factor and the storedauthentication factor, creating instructions indicating whether therequested transaction is verified by the customer; and outputting fortransmission the instructions to the issuer system.
 2. Thenon-transitory, computer-readable medium of claim 1, wherein thereceived authentication factor comprises secret information.
 3. Thenon-transitory, computer-readable medium of claim 2, where the secretinformation is a personal identification number (PIN).
 4. Thenon-transitory, computer-readable medium of claim 1, wherein thereceived authentication factor and the stored authentication factor eachcomprise biometric information associated with the customer.
 5. Thenon-transitory, computer-readable medium of claim 1, wherein theinstructions, when executed by the processor of the mobile device, causethe processor to perform a method further comprising: receiving thestored authentication factor from the smart card; and comparing thereceived authentication factor to the stored authentication factor. 6.The non-transitory, computer-readable medium of claim 5, whereinreceiving the stored authentication factor comprises reading the storedauthentication factor from the smart card.
 7. The non-transitory,computer-readable medium of claim 1, wherein the instructions, whenexecuted by the processor of the mobile device, cause the processor toperform a method further comprising: displaying, via a screen of themobile device, a prompt requesting that the customer initiatecommunication between the mobile device and the smart card.
 8. Thenon-transitory, computer-readable medium of claim 7, wherein initiatingcommunication between the mobile device and the smart card comprisestouching the smart card to the mobile device.
 9. The non-transitory,computer-readable medium of claim 7, wherein initiating communicationbetween the mobile device and the smart card comprises moving the smartcard toward the mobile device.
 10. The non-transitory, computer-readablemedium of claim 1, wherein the requested transaction is acard-not-present transaction request.
 11. The non-transitory,computer-readable medium of claim 10, wherein the requested transactionis an online transaction.
 12. A method for authorizing a payment, themethod comprising: receiving a payment authorization request from amerchant, the payment authorization request corresponding to a requestedtransaction and comprising an account identifier associated with afinancial account of a customer, the financial account having a smartcard associated therewith; transmitting a verification request to amobile device associated with the customer, the verification requestcomprising: a prompt for a card application installed on the mobiledevice to communicate with the smart card to receive an authenticationfactor associated with the smart card; receiving verification of therequested transaction from the mobile device based on the receivedauthentication factor; and approving or denying the transaction based onthe received verification by transmitting an authorization signal to themerchant.
 13. The method of claim 12, wherein the authentication factorcomprises secret information.
 14. The method of claim 13, wherein thesecret information is a personal identification number (PIN).
 15. Themethod of claim 12, wherein the authentication factor and the storedauthentication factor each comprise biometric information associatedwith the customer.
 16. The method of claim 12, wherein the requestedtransaction is a card-not-present transaction request.
 17. The method ofclaim 16, wherein the requested transaction is an online transaction.18. The method of claim 12, wherein the authentication factor is storedon the smart card.